敏捷的每一句話，我們都只記住了前半句；出事的，全是被省略的後半句。

一場還不敢叫 Retro 的會

昨天客服主管連續三個「不是這樣」之後，退款案實質上停了下來。既然停了，該盤點了。

PM 把大家找進會議室。沒有人好意思把這場會叫做 Retro——要回顧，總得先有一輪完整的東西可以回顧，而這個案子只有一地碎片。姑且叫檢討會。

白板上，有人把這一個多月攤成一條時間軸：

一句話需求：「幫我加一個線上退款功能」，當天開單
        ↓
「先做再說」，對齊會議沒開成
        ↓
整合日：三條線各自全綠，接起來全紅，
三個人都說「我這邊是好的」
        ↓
聯調到一半，才第一次有人問：怎樣叫退款成功？
        ↓
Demo：三個「不是這樣」——七天簽核、已出貨、發票折讓

看著這條軸，年輕的後端工程師小聲說了一句：

「可是，我們不是都照敏捷做了嗎？」

這句話問得很誠實。今天就來回答它。

當時團隊怎麼理解敏捷

把這一路上大家說過的話收集起來，會得到這個團隊的敏捷觀：

需求反正會變，先寫清楚也是白寫；敏捷擁抱變化，客戶要改就改；能跑的軟體勝過完整的文件，所以文件能省則省；當面講比較快，寫下來是官僚；反正是迭代，錯了下一輪再改。

老規矩：每一句單獨看，都有幾分道理。而且說真的，每一句的前半都真的來自敏捷——這些不是團隊瞎編的。

問題出在每一句都被砍掉了後半。

白板上的五組對照

檢討會真正有價值的產出，是有人把「我們以為的敏捷」跟「實際發生的事」並排寫在白板上。整理起來是五組：

需求可變
≠ 不用需求

擁抱變化
≠ 不用管理 Change

Working Software
≠ 不用 Acceptance

Individuals and Interactions
≠ 不留 Decision

Iteration
≠ 一直返工

一組一組對號入座。

第一組：需求可變 ≠ 不用需求。

「幫我加一個線上退款功能」之所以當天就能開單，理由正是「需求反正會變，寫了也白寫」。結果是三個人用三種想像各自補完：客服想的是三天變三分鐘，後端想的是呼叫金流 API，前端想的是一顆按鈕。而七天核准權限、已出貨不能直接退這些規則，從頭到尾沒有人問。

需求可變，變的是答案；問題本身還是得先定義。這個團隊省掉的不是「寫文件」，是「搞清楚要解決什麼問題」——後者不管什麼方法都省不掉。

第二組：擁抱變化 ≠ 不用管理 Change。

Demo 之後團隊喊「需求一直改」，但昨天已經對過帳：那三條規則沒有一條被承諾過，也沒有一條是新生的。那不是 Change，是 Discovery。

更難堪的是：就算真的是 Change，這個團隊也沒有任何東西接得住它。沒有紀錄、沒有報價（Day 05 說過，沒有免費的 Change）、沒有重新承諾。擁抱變化的前提是看得見變化——變化被記下來、被算過代價，才有「擁抱」可言。看不見的變化不會被擁抱，只會把你輾過去。

第三組：Working Software ≠ 不用 Acceptance。

整合日之前，這個案子的軟體全都在 work：前端會動、後端會動、金流串接單元測試全綠。按照「能跑的軟體最大」的理解，大家都完成了。

然後端到端一路紅。再然後，大家發現連「綠」都是假的：金流回 200 只是受理，前端那個「退款成功」畫面，蓋在錯誤的完成語意上。

沒有 Acceptance，「working」的定義會退化成「在我這段會動」。Working Software 的本意是拿可運作的東西來驗證，它是證據，不是免驗收的通行證——而驗證需要判準，判準就是 Acceptance。

第四組：Individuals and Interactions ≠ 不留 Decision。

Webhook 三方都以為不歸自己，因為「誰負責串」這個決定從來沒有被做成、更沒有被寫下。前端等 boolean、後端回狀態字串，因為介面各自腦補，誰也沒告訴誰。

重視個人與互動，意思是對話比僵硬流程重要，不是對話的結論可以不落地。講好的事沒有落地，過一個月等於沒講。而這個團隊還要更慘一層：那場該發生的對齊會議，被「先做再說」擋掉了——連 interaction 本身都省了，直接跳到省 Decision。

第五組：Iteration ≠ 一直返工。

整合炸掉重接一次、完成語意翻案重改一次、Demo 之後三條規則又要重工一次。過程中一直有人安慰彼此：「敏捷嘛，本來就會一直改。」

Day 03 說過，敏捷賣的是 Feedback：每一輪結束，團隊該知道一點原本不知道的事，然後據此決定下一步。這個案子第一次真正的 Feedback，是 Demo 那天客服主管開口——而那時三條線都已經蓋完了。

之前的每一次「再做一遍」，沒有帶回任何新認知，只是把同一段沒定義清楚的路重走。Iteration 前進的是認知；返工消耗的只有人。

這五個後半句，以前是誰在做？

白板寫到這裡，其實還欠一個問題：這五個誤解，並不是這個案子才出現的。以前怎麼都沒炸？

因為以前每個後半句都有人做——同一個人。

需求沒寫清楚，他會把該問的十件事問完；介面沒定義，他跟對面那位有老交情；怎樣算完成，他知道客戶會皺哪種眉頭；決定為什麼這樣做，他記得。第二部整整七天講的就是這件事。

所以組織學到的是：前半句就夠了，敏捷就是可以這麼輕。

這一次他被借調去救另一個專案，前半句第一次獨自上場。於是大家終於看見：後半句的工作從來沒有消失過，它只是一直有人默默兼職。

這次到底誰在吸收代價？

老規矩。這次直接看全案累計到今天的帳：

Scope       □   一項都還沒少（也還沒人敢談少）
Time        □   整合期爆掉的那筆，記過帳了
Cost        □
Quality     ■   錯誤的「退款成功」畫面、錯的訂單狀態，全蓋在錯的語意上
Risk        □   前五天堆的未爆彈，正在逐顆兌現
人          ■   聯調加班、三度重工，以及這間會議室裡所有人   ← 還是這格

值得注意的是順序：Risk 那格是前幾天勾的，現在帳單陸續寄達，付款的欄位換成了 Quality 跟人。未爆彈不會消失，只會換一格記帳。

把敏捷只學一半的團隊，省下的每一個後半句，最後都由品質跟人買單。

今日 Artifact｜敏捷誤解對照卡

把白板上那五組收成一張卡。不用開會，對照你自己的團隊，誠實勾選「我們以為」那邊中了幾條：

□ 我們以為：需求會變，所以不用定義問題
  其實是：答案可以變，問題必須先問清楚

□ 我們以為：擁抱變化，所以改了就改
  其實是：變化要被看見、被記錄、被算過代價，才擁抱得起

□ 我們以為：能跑的軟體最大，驗收是官僚
  其實是：「能跑」需要判準；沒有 Acceptance，能跑＝在我這段會動

□ 我們以為：當面講就好，寫下來是浪費
  其實是：對話優先，但結論要落地成看得見的 Decision

□ 我們以為：反正是迭代，錯了下一輪改
  其實是：每一輪要帶回新的認知；沒有 Feedback 的重做叫返工

五條全沒中，你們學的是完整版。中了任何一條，先別急著怪敏捷——它的後半句可能正由你們團隊裡的某個人默默兼職，或者，正在等一個沒有人兼職的案子引爆。

今日一句

敏捷的口號都是省略句；被省略的部分不會消失，只會變成某個人的工作，或某一天的事故。

盤點完五組誤解，會議室裡終於有人問出那個最直覺的問題：

「所以……答案是回去做瀑布嗎？」

明天回答這一題。先說結論的形狀：問題可能不在我們太敏捷。